Business Analyst Community & Resources | Modern Analyst

What does “good” look like for an AI feature—and how do you test it?

Adrian M. — Mon, 29 Dec 2025 21:01:00 GMT

“Good” for an AI feature is not just accuracy. “Good” means the feature delivers the intended outcome reliably, safely, and consistently within defined boundaries—and you can prove it.

What “good” looks like (the BA checklist)

A well-defined AI feature typically has targets in these areas:

1) Outcome (value)

What business outcome improves (time saved, errors reduced, conversion increased)?
What metric proves it?

2) Quality

Accuracy (or usefulness) at an agreed threshold
Consistency (similar inputs → similar outputs)
Latency (response time)
Cost (especially for AI inference)

3) Safety & compliance

No prohibited content
No leakage of sensitive data (PII, credentials)
No unsafe actions (especially if the AI can act in systems)

4) Trust & transparency

Users can understand why it produced an output (explanations, sources, confidence)
The system handles uncertainty gracefully (“I’m not sure, here’s what to do next”)

5) Operability

Monitoring in place (drift, anomalies, failure rates)
Rollback/kill switch criteria defined

How you test it (practitioner approach)

Testing AI features blends traditional testing with evaluation:

A) Test with representative scenarios

Build a test set of real-world cases (including edge cases)
Include “hard cases” and “red team” attempts (misuse, injection, sensitive data prompts)

B) Define measurable acceptance thresholds
Examples:

“At least 90% of outputs meet rubric score ≥ 4/5”
“High-risk actions require human approval 100% of the time”
“No PII appears in outputs in the test set”
“Confidence below X triggers escalation”

C) Test behavior under uncertainty

What does it do when data is missing?
Does it hallucinate or does it ask for clarification?
Does it choose safe defaults?

D) Monitor after release
Because AI behavior can change, “good” must be maintained:

track drift,
review exceptions,
adjust guardrails and evaluation sets.

What are “guardrails” in an AI-enabled product?

Adrian M. — Mon, 29 Dec 2025 20:58:00 GMT

Guardrails are the rules, controls, and safety mechanisms that ensure an AI feature behaves within acceptable boundaries—even when users try to push it, inputs are messy, or the system is uncertain.

Think of guardrails as the difference between:

“AI that can do things”
and
“AI we can responsibly operate in production.”

Guardrails typically include

Behavior guardrails

prohibited actions
prohibited content
allowed outputs

Data guardrails

what data can/can’t be accessed or used
retention rules
residency or compliance constraints

Decision guardrails

risk tiering (low/medium/high)
decision rights (when the agent can act)
human review requirements

Operational guardrails

monitoring and alerts
rate limiting / throttling
rollback / kill switch criteria
audit logs

Why BAs should care

Guardrails are often the “missing requirements” that prevent:

reputational damage,
compliance issues,
security incidents,
and runaway automation.

A BA helps turn vague stakeholder concerns (“this feels risky”) into specific, testable requirements (“this must never happen; if it happens, stop and alert”).

What distinguishes a functional requirement from a solution or design constraint?

Adrian M. — Sat, 10 May 2025 01:02:00 GMT

Functional requirements describe what the system must do, while solution or design constraints set the boundaries on how the system may be built.

Definitions

Functional requirement (FR): An externally visible behavior that satisfies a business need. Example: “The system shall calculate the total order price, applying state-specific sales tax and any active promotions.
Solution / design constraint (SC): A rule or limitation that restricts technology, architecture, process, or environment. Example: “The calculation must reuse the existing SAP tax engine and complete in ≤ 2 seconds.”

Key Differences

Aspect	Functional Requirement	Solution / Design Constraint
Purpose	Deliver a capability or service	Limit the implementation space
Focus	Outcomes, interactions, user value	Tools, standards, timing, budget, compliance
Validation	User acceptance tests, use-case walkthroughs	Design reviews, architectural conformance, audits
Flexibility	Multiple ways to meet the need	Narrows or eliminates options

Why It Matters

Clarity: Separating FRs from constraints prevents “design by requirement,” keeping the what independent of the how.
Innovation: Teams can explore creative solutions as long as they respect immovable guardrails.
Traceability & Testing: FRs map to user acceptance tests; constraints map to design or non-functional verification, reducing gaps at audit or release time.

Illustrative Scenario

A retailer wants faster checkout.

FR: “The POS system shall apply loyalty discounts and display the final total to the cashier.”
SCs:
1. “The solution must run on existing Android POS tablets.”
2. “Data transmission must be encrypted to meet PCI-DSS requirements.”
3. “Discount calculation response time shall not exceed 1.5 seconds.”

The FR articulates the desired capability, leaving room for various algorithms or UI designs; the SCs fence those choices with technology, regulatory, and performance limits.

What is Decomposition?

Adrian M. — Wed, 11 Oct 2023 02:30:00 GMT

Decomposition is the process of breaking down complex systems, problems, or tasks into smaller, more manageable and understandable components or sub-parts. It is often used in various fields, such as software development, project management, and business analysis, to simplify complex problems and facilitate analysis, understanding, and problem-solving by addressing individual elements separately.

In requirements management, decomposition is the process of breaking down high-level or complex requirements into smaller, more detailed and manageable sub-requirements. This approach allows for a more in-depth understanding of what the system or product needs to accomplish and helps in creating a structured and organized set of requirements. It is often helpful to develop visual models which depict the hierarchical structure of the requirements. High-level or top-level requirements are subdivided into lower-level or more granular requirements. This hierarchy provides clarity and helps stakeholders understand the relationships between different requirements.

In systems development, decomposition refers to the process of breaking down a complex system or project into smaller, more manageable components, modules, or tasks. This approach is often used in software development, but it can apply to various systems development methodologies, including the systems engineering process.

In business analysis, decomposition refers to the process of breaking down complex business processes, systems, or problems into smaller, more understandable and manageable chunks. This technique is used to analyze, understand, and document the various aspects of a business or project, helping business analysts and stakeholders gain insights into the structure, functions, and interactions within an organization.

Here are some examples where a business analyst can use decomposition to their advantage:

Process Analysis - decomposition can be used to break down complex business processes into their individual steps or activities. This helps identify bottlenecks, inefficiencies, and areas for improvement.

Requirements Analysis - high-level business requirements are often decomposed into more detailed and specific functional and non-functional requirements. This process helps clarify what the business or project needs to achieve.

Data Modeling and Data Analysis - decomposition is used to break down complex data structures into their constituent data elements or attributes. This helps in the creation of data models and database schemas.

System and Component Analysis - in software or IT-related projects, decomposition can be applied to understand the various components, modules, and interfaces within a system. It helps in designing and building systems with a clear understanding of how the various pieces work together.

How can a GPT help the business/systems analyst?

Adrian M. — Sun, 09 Apr 2023 18:30:00 GMT

First, let’s define GPT. GPT stands for “Generative Pre-trained Transformer” and it refers to a type of deep learning artificial intelligence model that is trained on large amounts of text data to generate human-like text. A business/systems analyst could use generative pre-trained models, such as ChatGPT, in several ways to improve their efficiency and productivity...

What is a Concept Model?

Adrian M. — Mon, 09 Jan 2023 03:04:00 GMT

A concept model is a business analysis model whose purpose is to depict the core concepts of the problem or solution domain being studied. At its core, it consists of the clear definition of the terms (nouns and verbs) which are important to the organization or the given domain.

Depending on the need and the experience of the business analyst, the concept model would be made up of a visual representation of the model, definitions of each concept in the model, as well as the model structure showing the relationships among the concepts.

The IIBA BABOK Guide Glossary defines the concept model as follows:

“An analysis model that develops the meaning of core concepts for a problem domain, defines their collective structure, and specifies the appropriate vocabulary needed to communicate about it consistently.”

Elements of a Concept Model

In a comprehensive concept model, there are a number of different types of elements:

Nouns - These are the key “entities” or “classes” of the domain being considered. For example, for a banking system, the nouns in the concept model might include: account, customer, transaction amount.

Verbs - These are the key action terms which define the relationships among noun concepts. For example, for a banking system, the verbs in the concept model might include: deposit, withdraw, create. This results in relationships such as: customer deposits transaction amount, customer opens account, etc.

The Purpose of a Concept Model

The goal of the concept model is to enable the mutual understanding and communication of key concepts among all the project participants and stakeholders. The concepts defined in the model are then able to be consistently used when discussing project requirements, defining business rules, training new users, and much more.

Concept Model Representation

There are many ways and tools which can be used to create a concept model:

UML Class Diagram
Data Dictionary/Glossary
Entity Relationship Diagram
Ontology Definition Metamodel (ODM)
Concept Map

Having a concept model is often more important than the exact method of representing the model. It is better to start with a simple list of terms, a basic glossary, and then expand and refine the model as dictated by the needs of the project or organization.

What is the difference between IIBA BABOK tasks "Specify and Model Requirements" and "Define Solution Options", 2 of the 6 tasks covered within the “Requirements Analysis and Design Definition” knowledge area?

Chris Adams — Thu, 09 Jun 2022 21:13:00 GMT

The Specify and Model Requirements Task describes the “What”.

The Define Solution Options Task describes the “How”.

What is the difference between horizontal and vertical prototyping?

Chris Adams — Thu, 09 Jun 2022 16:07:00 GMT

Horizontal and vertical prototypes are sometimes used during the analysis and design phases of application development. They are useful for requirements elaboration and visualization, but can present some pitfalls. As long as analysts and teams are aware of the pitfalls to avoid, the pros of using prototypes generally far outweigh the cons. The type of prototype that should be used (horizontal prototype versus vertical prototype) depends on the specific goals of the team and the stage within the analysis and design process.

What is the business case for using personas?

Chris Adams — Mon, 09 May 2022 14:23:00 GMT

Many organizations that lack experience with personas don't fully understand the value of them. Furthermore, personas can be difficult for the inexperience team member to properly create. Intuitively people tend to think that in order to satisfy the needs of a large audience or wide array of users they need to make the functionality of the product or application as broad as possible. This is wrong. When you try to design for everyone, you delight no one. You end up with a very mediocre product. If you focus on delighting your primary persona then those represented by your secondary persona(s) should also be satisfied due to overlap in needs. A good analogy to remember is this: widening your target doesn't improve your aim.

Compare a user story versus a use case. What are the essential elements of each? When would you use one versus the other?

Chris Adams — Sat, 08 Jan 2022 22:08:00 GMT

The essential elements of a user story are:

The user
Statement of what the user needs to accomplish
Why the need to accomplish this

The essential elements of a use case are:

The Actor carrying out the use case
Summary of the use case
Success criteria
Scenario detailing the steps the Actor follows to achieve the success criteria.

What is a JAD Session and what is the Business Analyst's role in one?

Chris Adams — Sat, 08 Jan 2022 18:00:00 GMT

A JAD is a Joint Application Development (or Design) meeting. It is an opportunity for stakeholders with different points of view to come together to understand business requirements and brainstorm what the best technical approach might be for meeting the customer's needs.

What are some pros and cons of requirements reuse?

Chris Adams — Mon, 13 Dec 2021 17:28:00 GMT

Requirements reuse is when the same written requirement is used repeatedly within a single project, across a product line, or even across an enterprise. Requirement reuse can be as simple as an analyst copy/pasting requirements from a previous project, or it can be as sophisticated as having a central repository of requirements that documents link to.

What are the Business Analysis Knowledge Areas?

Chris Adams — Tue, 07 Dec 2021 20:56:00 GMT

This question is an easy way for a hiring manager or an HR professional to screen out candidates who may have under-invested in their career or may lack understanding of the business analysis profession. The 6 Knowledge Areas are:

Elicitation & Collaboration
Requirements Analysis & Design Definition
Solution Evaluation
Requirements Life Cycle Management
Business Analysis Planning & Monitoring
Strategy Analysis

What approach should a business analyst take when gathering requirements from high level executives versus the end users?

sonavi — Mon, 09 Aug 2021 13:30:00 GMT

For the most part, the methods and techniques for gathering requirements are the same regardless of whom the stakeholders are: interviews, focus groups, questionnaires, requirements workshops.

However, there are definite things that the business analyst should consider when gathering requirements from high-level executives vs. the end users. The business analyst should tailor his approach and expectations based on the stakeholder type.

What is an FRD (Functional Requirements Document)?

Adrian M. — Fri, 16 Apr 2021 15:50:00 GMT

What you ever wondered, or have been asked, “What is an FRD?”

At the core, an FRD or Functional Requirements Document serves as a contract for formal statement, between the business stakeholders and the technology team, on an application’s functional requirements. The FRD is generally produced by the technical team in response to the business requirements (captured in a BRD - Business Requirements Document, PRD - Product Requirements document, or some other suitable format).

The key purpose of an FRD is to bridge the gap between business and technology. It’s where project stakeholders and the technical development team meet. The creation of the FRD forces and ensures collaboration and address both sides of the coin:

Business - it restates the business requirements in terms of functional features and capabilities to be supported by the new system or platform. This ensures the project team understands the business requirements and are on their way to implement a solution which addresses the business needs or problems.

Technology - it captures key technical constraints and commitments as well key interfaces to external systems

While created by the solution team, the FRD should be solution independent (in general) aka it should express what the application should do and not how it should do it. The FRD should not commit the technical team to a specific design.

The Functional Requirements Document (FRD) is one way to express functional specifications and define the requirements and functional solution direction of software solution. The FRD is not the only way - there are other functional specification formats and templates, depending on methodology and organizational needs::

Systems Requirements Document (SRS)
Use Cases
User Stories
High-Level Impact Assessment

While FRD templates vary, some of the more common elements of a functional requirements document are (just a suggestion):

Business process and workflows - provides a view of the desired target state business process models outlining which steps in the process will stay as-is and which steps will be either automated or impacted by the solution at hand.

Functional Requirements - these are the traditional “the system shall…” type requirements and can be broken into multiple subsections such as:
- User Requirements
- Regulatory Requirements
- Compliance Requirements
- User Interface Requirements

Operational Requirements - while some may be functional in nature, the operational requirements tend to focus more on administrator level capabilities and needs:
- Role Based Security
- Audit Trail
- Configuration

Data Requirements - describe the data which needs to be supported by the system. This section may include logical data models, data migration and conversion requirements. It is not uncommon to also see data flow diagrams describing the conceptual flow of data.

Non-Functional Requirements - these generally describe attributes of the system which, when done right, may never be observed by the users which use the functional capabilities.
- Security Requirements
- Performance Requirements
- Capacity
- Fault Tolerance
- Data Retention
- Recoverability
- Additional sections or information which may be found in an FRD:
- Background
- Scope
- List of Project Stakeholders
- Assumptions
- Constraints

Your turn!

Do you use Functional Requirements Documents?
How do you structure your FRD?
What is an FRD, for you?

Describe some pros and cons of using templates that aid in creation of BA deliverables.

Chris Adams — Fri, 12 Mar 2021 17:53:00 GMT

Templates can be useful, but with many tools available to the business analyst they come with their pros and cons.

What is the Six Thinking Hats model?

Chris Adams — Sun, 13 Sep 2020 16:00:00 GMT

The Six Thinking Hats is a role-playing model presented by Edward de Bono in 1986. It serves as a team-based problem solving and brainstorming technique that can be used to explore problems and solutions and uncover ideas and options that might otherwise be overlooked by a homogeneously thinking group.

What are SMART requirements?

Adrian M. — Fri, 14 Aug 2020 01:57:00 GMT

At first glance, smart requirements are requirements which are well thought out, well written, selected with the end user in mind, consider the customer's experience, consider trade-offs when it comes to implementation (such as cost, time).

However smart requirements, or better put SMART Requirements refer to an acronym whose goal is to help you come up with really good requirement statements:

Specific
Measurable
Attainable (appropriate, actionable, achievable)
Realistic
Testable and Traceable

There are other mnemonic acronyms which help a business analyst ensure the requirements are the best that they can be:

CLEAR
- Collaborative
- Limited
- Emotional
- Appreciable
- Refinable

PURE
- Positively stated
- Understood
- Relevant
- Ethical

CPQQRT
- Context
- Purpose
- Quantity
- Quality
- Resources
- Timing

Why are modeling techniques so important to Business Analysts, and how do you choose the right ones for your project?

Chris Adams — Mon, 08 Jun 2020 17:30:00 GMT

Grouping related items (whether requirements, ideas, business processes, etc.) into a diagram or model is just a way of forming them into recognizable and (hopefully!) familiar patterns. And the short-term memory limit is much less constraining if people are asked to remember and absorb a few different patterns as opposed to dozens of individual bits of information.

How should the Business Analyst begin the requirements elicitation process for a new product or solution?

Chris Adams — Sun, 10 May 2020 22:00:00 GMT

When beginning analysis on a product or solution that is needed to meet a business need, the Business Analyst needs to obtain a basic understanding of the pain points that the business wants to address.

At this stage of this process there is only a need to get the equivalent of a business executive’s point of view. That is, the analyst needs to get a high level understanding of the pain points, framed through the six basic questions someone needs to ask in order to understand any object: Who, What, Where, When, How, and Why. Let’s take each of them in turn.

Why would the Business Analyst use Kano Analysis?

Chris Adams — Sun, 12 Apr 2020 18:20:00 GMT

Kano Analysis refers to the process of analyzing a product or system requirements to determine what the perceived impact will be on customer satisfaction.

The Kano model categorizes product attributes or system requirements into 3 categories to determine the perceived customer satisfaction: Unexpected Delights, Performance Attributes, Must Have Attributes.

What is a Pugh Matrix?

Chris Adams — Sun, 12 Apr 2020 18:10:00 GMT

The Pugh Matrix is a criteria-based decision matrix which uses criteria scoring to determine which of several potential solutions or alternatives should be selected. The technique gets its name from Stuart Pugh and has become a standard part of Six Sigma methodology. It is typically used after the development of the VOC (Voice of the Customer) and after the creation of a QFD (Quality Function Design).

How are personas used in requirements elicitation on agile projects?

Chris Adams — Sun, 13 Oct 2019 22:30:00 GMT

A persona is a description of a fictional person, representing key characteristics of a specific user class or group. Personas provide models of the user community that make it easier for project teams to understand and predict how users will act and react, based on characteristics such as age, education, knowledge, and attitudes.

A key purpose that personas serve on agile projects is in the formulation of user stories, so that each story is written from the perspective of a distinct person with known attributes – rather than a generic “user” or job role.

Personas are also invaluable in making design decisions, and determining how usability can be optimized for the user community.

As with all other aspects of Agile projects, personas should be developed collaboratively amongst the team and refined iteratively over the course of the project.

Here is a short video that highlights the need to validate personas against real data and real user information, as well as the benefits of building personas iteratively as more information becomes known – The Secret to Developing Effective Personas.

--
Sandy Lambert
Business Architect
LinkedIn Profile

What are some of the problems you are faced with when gathering requirements?

rosy — Sun, 08 Sep 2019 16:50:00 GMT

While this is a broad question, it is often used by interviewers to find out whether the candidate has actually performed requirements elicitation in the past and has experienced its challenges. Once challenges are mentioned many interviewers proceed to ask what the candidate has done or would do in order to overcome those problems.

So, here are some of the problems faced by business analysts during the requirements elicitation/gathering activities:

What is Multi-Dimensional Prioritization of Requirements and What is the Benefit?

Chris Adams — Sun, 12 May 2019 15:06:00 GMT

Multi-Dimensional Prioritization is a structured and methodical approach to prioritizing requirements by evaluating each across multiple factors. It’s something that stakeholders and analysts often due intuitively when huddled together in a meeting. However, multi-dimensional prioritization brings structure, rigor and efficiency to this process. By assigning a numerical weight to each requirement across a number of predetermined categories, a resulting requirement priority can be obtained.

How do you prevent your application from being a confusing suite of features rather than one that meets a user's goals with ease?

Chris Adams — Mon, 14 Jan 2019 15:10:00 GMT

Many applications are designed and completed only to result in a confusing suite of features that is difficult for the user to navigate. So how can an analyst avoid this pitfall. The answer is Design Thinking, also sometimes referred to as Human Centered Innovation or Human Centered Engineering.

What are some key AI product design principles?

Chris Adams — Mon, 10 Dec 2018 01:10:00 GMT

As artificial intelligence (AI) technology advances and AI products become more prevalent and more powerful, the line between machines and humans starts to blur. AI products can perform a variety of tasks from synthesizing data and presenting helpful insights to behaving independently, learning new tasks, and predicting outcomes with astonishing precision.

Advancements in AI are beginning to change how people react to AI products and what they have come to expect out of a product's design. By following a few basic user experience principles, clarity can be brought to the increasingly complex world of AI products.

In which document do you include the Class Diagram (business requirements, functional requirements, software specification document)?

sonavi — Mon, 12 Nov 2018 16:20:00 GMT

Just like any other diagram, the Class Diagram is just a tool at the disposal of the analyst. In the absence of a set process, it is at the analyst’s discretion to determine when to use a class diagram. Therefore, in which analysis artifact/document a class diagram should be included depends on its use.

How is the Purpose Alignment Model used to prioritize requirements?

Chris Adams — Mon, 12 Nov 2018 16:00:00 GMT

The Purpose Alignment Model aids in prioritizing requirements and guiding investment decisions by rating requirements (which may be capabilities, processes or tasks) along two dimensions:

whether it creates market differentiation or contributes to the value proposition
whether it is critical for ongoing operation of the organization

What are micro-interactions in the context of user experience and design?

Chris Adams — Mon, 13 Aug 2018 14:22:00 GMT

Micro-interactions are the small focused instances where users and the website (or application) intersect. They are a way to actively interact with users in a simple, clear, and engaging manner.

As a BA (business analyst) approaching a new piece of work, who would you interview and what questions would you ask?

Guy Beauchamp — Sun, 08 Jul 2018 18:35:00 GMT

For any new piece of work a BA (business analyst) needs to know

1. who are the key stakeholders (i.e. those who can kill the project)

2. what are the key stakeholders specific and measurable measures of success (i.e. their objectives) and what VALUE for each objective MUST be achieved in order for the project to be considered a success (e.g. increase sales per order value by 5%)

3. what are the key stakeholders unmeasured measures of success (i.e. their principles that they would like to see happen but aren't going to measure and so the project cannot be assessed by them - e.g. an intuitive solution)

4. what are the key stakeholders high level requirements (i.e. what capabilities do they expect the solution to deliver - e.g. the ability to offer add-on sales during the order taking process)

5. what is in scope of the work in terms of processes, organization units, locations, data, applications, technology

6. what is the scope of the work in terms of time, money, project resources (people and materials)

7. who will the stakeholders nominate for determining further high level requirements and detailed requirements (e.g. subject or domain experts, middle management of operational teams, etc)

What is Gap Analysis?

Chris Adams — Sun, 13 May 2018 21:39:00 GMT

Gap Analysis is the process of comparing two things in order to determine the difference or “gap” that exists between them. Once the gap is understood, the steps required to bridge the gap can be determined.

How does the Business Analyst role change on an Agile project compared to projects using other software development methodologies?

Chris Adams — Mon, 12 Mar 2018 15:02:00 GMT

The role of the BA should actually change very little between different software development methodologies, although the tools and techniques used by the BA can vary according to the needs and attributes of any given project or development lifecycle.

The core responsibilities of a BA on a software development project include requirements elicitation, requirements analysis and requirements management – regardless of the project methodology. The type and format of requirements documentation are just tools, and a good BA has a wide range of tools at his or her disposal.

How are non-functional requirements defined and managed on Agile projects?

Chris Adams — Mon, 12 Mar 2018 14:55:00 GMT

Non-functional requirements (NFRs) are typically defined as backlog constraints on an Agile project, and are managed as part of both product backlog and scrum backlog. They are revisited as part of the ‘Definition of Done’ for each iteration or sprint. If the system does not meet any given NFR, that NFR may spawn new backlog items such as refactors or performance enhancements.

In User Centered Design, should analysts create a separate Personas for every demographic segment?

Chris Adams — Sun, 13 Aug 2017 18:45:00 GMT

Personas are used in User Centered Design to represent the audience that you are designing for. Each persona is a detailed profile of a fictional character which represents a different user segment. They are created in such a way as to bring a strong sense of realism to the users they represent. This helps create a visceral connection with the personas so that the system designer can really understand the users’ motivations for using the product. Personas primarily focus on a user’s attitudes and behaviors.

How is the 100-point method used to prioritize requirements?

Chris Adams — Sun, 09 Jul 2017 14:00:00 GMT

The 100-point method is a prioritization method that can be used to prioritize items in a group environment. Each person within the group is given 100 points which they can distribute as votes across the available items. The votes do not need to be distributed equally; rather a weighted distribution can be used to reflect the higher priority that some items warrant.

What are some steps the Business Analyst can take to avoid vague, incomplete or ambiguous requirements?

Chris Adams — Sun, 09 Apr 2017 20:55:00 GMT

Stakeholders often interpret requirements in a variety of different ways. Whether its from the natural ambiguity of conversational language or due to missing information, ambiguous and incomplete requirements can lead to project delays and budget overruns. But by keeping a few key considerations in mind the Business Analyst can dramatically improve the quality of product requirements.

What techniques have you used to elicit business requirements?

Adrian M. — Sun, 09 Apr 2017 17:50:00 GMT

There are a number of methods used for eliciting and discovering requirements. These methods can be categorized into two main categories: Collaborative Interaction and Restricted Interaction.

What types of actions can help the business analyst avoid Analysis Paralysis?

Chris Adams — Sun, 12 Feb 2017 22:10:00 GMT

Analysis Paralysis is the dreaded black hole of projects. So, how do you recognize that you might be in Analysis Paralysis. Here are a few symptoms that might clue you in.

What is a Mis-Use Case?

Chris Adams — Sun, 08 Jan 2017 20:57:00 GMT

A Mis-use Case, which is derived from Use Case, is a requirements and process modeling term used to describe the steps and scenarios which a user performs in order to accomplish a malicious act against a system or business process. They are still use cases in the sense that they define the steps that a user performs to achieve a goal, even if the goal isn’t a positive one or a desired one from the perspective of the business process or system designers.

What are the essential components of a use case?

Chris Adams — Sun, 09 Oct 2016 18:57:00 GMT

Use case name
Actors
Assumptions/Pre-conditions
Post-conditions
Business rules
Normal process flow
Alternate process flows

What are the basic types of actors that can exist in a Use Case Diagram?

Chris Adams — Sun, 09 Oct 2016 17:00:00 GMT

Actors can be primary or secondary actors. Primary actors initiate a use case, while secondary actors support a use case or receive something of value from the use case.

Describe the requirement engineering process SQUARE.

Chris Adams — Sun, 11 Sep 2016 00:00:00 GMT

SQUARE stands for Security Quality Requirements Engineering. It is a requirements engineering process developed by Carnegie Mellon University’s Software Engineering Institute (SEI) which focuses on eliciting and documenting security requirements. Since security requirements are often not given the focus that they deserve and since trying to incorporate security requirements later in the software development lifecycle costs more than planning for them upfront, the SEI developed a nine-step process to ensure that quality security requirements can be gathered, categorized, prioritized, and validated early on in the software development lifecycle.

What are the benefits of a developing a business entity model early in the analysis process?

Chris Adams — Sun, 10 Jul 2016 21:00:00 GMT

There are numerous benefits to developing a business entity model (also called a logical data model), early in the analysis process. To understand these benefits, the information captured in the business entity model needs to be understood.

How do you avoid requirement conflicts while making changes to an existing system where no documentation exists?

Chris Adams — Sun, 13 Dec 2015 20:41:00 GMT

Companies with small IT departments or analysis teams often lack a well defined analysis process. It's not uncommon for analysts to be hired onto a team and find that they are being asked to assist with requirements and new features for a system where no documentation exists. In this case, the analyst needs to create a minimal amount of documentation retroactively.

What is RML (Requirements Modeling Language)?

Chris Adams — Sun, 10 May 2015 23:02:00 GMT

Requirements Modeling language is a collection of diagrams used to model software from the business analysis or product management perspective.

What is the difference between a use case alternative flow and an exception flow?

cadams — Sun, 12 Oct 2014 06:13:00 GMT

A use case specification describes the functionality of a system in terms of a sequence of user-system interactions. The main flow of events describes a single path through the system. It represents the most common way that the use case plays out successfully and contains the most common sequence of user-system interactions. Other scenarios or paths through the system are described in alternative flows and exception flows. So what is the difference between and alternative flow and an exception flow?

When implementing a purchased solution should your requirements and design documents cover features that were not requested but come with the package?

Chris Adams — Sun, 07 Sep 2014 18:22:00 GMT

When implementing a purchased solution at a minimum each additional feature needs to be assessed to determine its potential positive or negative impact.

Why is requirements traceability important on a project?

Chris Adams — Fri, 06 Jun 2014 04:07:00 GMT

Tracking and managing requirements traceability offers several valuable benefits to a project:

Minimize Risk and Manage Costs. Requirements traceability lets you identify and analyze the upstream and downstream impacts of any requirements change, so those impacts can be effectively managed and mitigated.
Manage Scope. Traceability provides an understanding the relationships between requirements and identifies stakeholders who have a vested interest in each requirement, which supports better decision-making about project scope and proposed changes throughout the project.
Improve Quality. Traceability allows individual requirements to be managed within the context of the full solution, and helps preserve the integrity of the end-state solution throughout each development cycle or product release. It also helps ensure that all requirements are fully tested and enables effective integration, system and regression testing.
Increase Stakeholder Engagement. Requirements are clearly linked to vested stakeholders, giving greater visibility of the value achieved for each stakeholder group throughout the project lifecycle.
Reduce Development Time. The ability to identify and manage groups of related requirements results in more efficient and effective planning, and streamlines product development.

--
Sandy Lambert
Business Architect
LinkedIn Profile

What is an epic, and what purpose does it serve on an Agile project?

Chris Adams — Fri, 09 May 2014 14:58:00 GMT

Business epics are large, typically cross-cutting initiatives that encapsulate new development needed to realize certain business benefits. One or more epics can form the basis for the business case that justifies and initiates a project.
Epics are often used as placeholders for new ideas that have not been thought out fully, or whose full elaboration has been deferred until actually needed. Epics are then evolved into split into multiple user stories that help Agile development teams effectively manage and groom their product backlog.

--
Sandy Lambert
Business Architect
LinkedIn Profile